The development process of a business application or other data processing system begins with determining specifications of that system. The determined specifications are described by using, for example, the Unified Modeling Language (UML) diagrams and formal languages.
Before starting to write specifications with UML or a formal language, the development team has to define what the system is supposed to do. This phase needs the knowledge of actual business activities. Expertise in UML modeling and formal languages is then used to describe specific system requirements as determined by the preceding phase. UML offers various forms of graphical representation for system modeling, such as class diagrams and activity diagrams. These standardized diagrams help third-party persons to understand the system specifications.
Typically, business practitioners have a thorough knowledge of their work, but they are not experts in the field of UML and formal languages. System engineers, on the other hand, know all about UML and formal languages, but may lack knowledge of actual business activities. Accordingly, business practitioners and system engineers have to work together to write UML scripts and other documents, although this approach may be slow and inefficient.
To overcome the above inefficiency issues, there is proposed a technique of converting, for example, natural-language sentences into a formal-language script so that a computer can translate it into executable programs. See, for example, Japanese Laid-open Patent Publication No. 7-28630 (1995).
Formal-language scripts are suitable for automated parsing by a computer. But, unlike graphical models, they are not easy to understand for average people. To build an easy-to-understand system model, business practitioners and system engineers still have to work together, while putting the efficiency issues aside, to combine their knowledge and expertise about business activities and modeling languages such as UML.